In distributed software systems, agents, also often called endpoints, devices, or user agents, communicate with each other and/or with central devices, such as servers. For example, an agent may both send and receive information, such as in a telephone-like device, or file/media sharing application. An agent may only receive (or request and receive) information, such as in a television-like device, a web client, or streaming media viewer agent. An agent may only transmit information, such as with a camera that is only able to stream information to a central server for others to obtain.
These agents may be realized in the form of a software application, a hardware device, or a hardware device running a software application which implements the agent. The agent may have a user associated with it, for example in the case of a phone or mail system where the agent processes messages for a particular user's number or address, or the agent may operate without an associated user.
In traditional client-server (CS) architecture, such as the example shown in FIG. 4, agents 402 and 404 are connected to a centralized server 406, which acts on behalf of the agents, via network connections propagated through data network 400 using a client-server protocol. The behaviors or services that the central server 406 may provide to each agent include, for example, registration, or storing a mapping of a user's unique name to a network location of the agent associated with the user; presence information, or information about the user's availability, desire to be disturbed, etc.; locating a remote agent and proxying messages to that agent; locating a remote agent and referring or redirecting the agent to that party (often referred to as “discovery” or “rendezvous” capability); storage and/or distribution of information used by applications (such as web pages, media files, documents, etc.); storage and/or distribution of information such as configuration information; storage and/or distribution of information such as system warning or downtime information; storage and/or distribution of information related to system or software updates; storage of and/or distribution of messages in text, audio, video, or other form for later retrieval or delivery; providing security and asserted identity between various communicating parties; storing and delivering messages for a user who is unavailable; providing interactive voice response mechanisms; and providing information about resources stored by the remote agents and how to retrieve the information from the remote agents.
Peer-to-peer (P2P) mechanisms exist to distribute many of the services enumerated above. In a P2P communications system, one, more, or all of the functions that would normally be performed by a centralized server 406 are instead performed by a distributed group of the agents themselves, working together to collectively provide the service. For example, if user agents 402 and 404 were to use a P2P protocol instead of a CS protocol, then much of the functionality of server 406 would be provided by the P2P agents 402 and 404. In such cases, some aspects of communications between the agents might be identical to the behavior of an agent connecting to the central server. However, one or more critical aspects would differ in that the distributed group of agents performs a task that is, in the client-server protocol, performed by central server 406.
The following example illustrates how a client-server model may differ from a peer-to-peer model. In the Session Initiation Protocol (SIP), locating a remote party in a CS model involves several steps. At a high level, an agent 402 wishing to make themselves available for communications first registers, or sends a message or messages, to a central server 406, providing the location (IP address or other information required to route information) of the agent 402 and a well known name or address of record that refers to that agent's user. When a calling agent 404 wishes to send a message to the agent 402, it either sends requests to the central server 406 asking for the location of the remote agent 402 and then sends the message directly to the agent 402, or it sends the message to the server, which then routes or redirects the message so that it reaches the intended agent endpoint 402.
In a P2P model, registrations (the mappings between the user's well-known, unique name and current network location) are instead sent to one or more of the other agents that make up the distributed group of agents. These agents collectively maintain the mappings that would normally be maintained by the server. Using a P2P protocol to communicate over network connections, calling agents contact and work with one or more other agents (dependent upon the exact nature of the P2P algorithm) to locate the agent that is storing the registration. One or more intermediate agents or data provided by one or more agents, rather than a central server or information from a central server, is thus used to locate and communicate with the remote party's agent.
This P2P location mechanism (and, more generally, any other mechanism beyond location that is distributed among the end agents rather than being provided by a central server) requires special P2P functionality that is not normally present in CS agents. Implementations of a P2P system have to date taken three approaches: implementing a completely new agent containing P2P functionality, significantly modifying an existing agent to include P2P functionality, or using a separate, standalone “adaptor node” agent to receive the calling agent's CS protocol and make new P2P protocol calls on behalf of the calling agent.
Implementing a new P2P agent or modifying a CS agent to include P2P functionality both have a number of shortcomings. They require significant new engineering effort. They cannot immediately leverage all work on existing agents, since current agents require modification to operate. Finally, work done to modify one application client in no way improves the performance of other applications—each must be modified separately to perform the operations in a distributed fashion.
Because of these shortcomings, a standalone adaptor agent, often called an adaptor node or adaptor peer, has been attempted, as illustrated in FIG. 5. Such an adaptor agent 504 runs as a member of a P2P network of agents which also includes P2P agents 506 and 508. These P2P agents communicate with each other over P2P network connections via a data network 500 using a P2P protocol. An unmodified CS agent 502 is explicitly configured to connect to the adaptor agent 504 over a network connection using a CS protocol. This network connection may be external (between two physical machines) or internal, using a virtual machine or loopback, but must always be explicitly configured in the unmodified CS agent 502. The adaptor node 504 acts as a central server in the view of the unmodified CS agent 502, but participates as a full P2P agent in the distributed group along with peers 506 and 508.
In some cases, the use of an adapter node works to allow unmodified CS agents to connect to a P2P network, but there are a significant number of problems with this approach, as well as cases where it fails. For example, problems arise with certain protocols that allow agents to initiate connections directly with other agents when the location of these have already been determined. In such cases, it may be difficult to ensure that the unmodified CS agent 502 does not become confused and try to communicate directly with P2P agents 506 or 508 rather than through the adapter agent 504. Failure to use the adaptor agent 504 for all communications can result in incorrect or corrupted P2P state information, or result in agents 506 and/or 508 receiving messages that they are unable to understand or process. A further problem is that most newer protocols, including the P2P protocols to which this concept applies, are designed with increased security. Since an older CS protocol is used between the unmodified agent 502 and the adaptor node 504, possibly traveling over an unsecured network or on a virtual network inside a multi-user machine, the advantages of the newer security mechanisms are not realized. Another problem is that if the adaptor agent 504 is located on a different host than the calling agent 502, the calling agent cannot function properly if the host running the adaptor agent 504 fails. In the event both 502 and 504 operate on the same host, the calling agent 502 will not operate in the event that the adaptor node application crashes. There may be no good mechanism for the adaptor agent to restart, or to even detect that the adaptor node has failed. Additionally, because the proper function of this system requires the calling agent 502 to be configured to communicate with the adaptor node 504, this mechanism is susceptible to misconfiguration.
Kruppa et al. in US Pat. Pub. 2009/0316687 discloses a P2P distributed call center method for high-level management of how to handle incoming calls to a call center. The technique is a layer on top of a communications system, and not a communications system itself. While standard P2P communications may be part of the underlying system, there is no teaching or suggestion by Kruppa of converting CS protocol to P2P protocol at the basic level of call control.
In view of the above, there is still a need for techniques that help overcome the existing challenges in converting client-server agents to peer-to-peer agents.